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Intellectual Property Rights 
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respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
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Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ETSI Project Digital Enhanced Cordless Telecommunications 
(DECT). 

The present document is based on DECT Common Interface (CI) specification EN 300 175, parts 1 [1] to 7 [7], to 
enable DECT terminals to interwork in the public and private environment. 

In addition, for the purpose of interoperability and wherever it is found appropriate, the present document takes into 
consideration the requirements of: 

• the DECT Generic Access Profile (GAP), EN 300 444 [10] to enable the same DECT portable part (PT) to 
interwork with a DECT fixed part (FP) complying to the GAP mainly signalling requirements, irrespective of 
whether this FP provides residential, business or public access services. 

General attachment requirements are based on EN 301 406 [11]. 

Further details on the DECT system may be found in TR 101 178 [9]. 
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Scope 



The present document specifies that set of technical requirements for Digital Enhanced Cordless Telecommunications 
(DECT) Fixed Part (FP) and DECT Portable Part (PP) necessary for the support and provision to the user of Multimedia 
Messaging Services (MMS) when provided over a fixed line access network. 

From architectural point of view the present document specifies an End System (ES) configuration, which assumes 
termination of many of the protocols required by the Fixed line Multimedia Messaging Service (F-MMS) as defined in 
ES 202 314-4 [17] in the DECT Fixed Termination (FT) and transport of as minimum as possible however sufficient for 
the service operation data over the DECT air interface to the DECT Portable Termination (PT). 

NOTE: The specified requirements can be applied also for the provision of MMS services in a business system, 
e.g. IP based PBX, that has fully implemented the requirements of the F-MMS services as defined in 

ES 202 314-4 [17]. 

The specification aims at ensuring interoperability between FTs and PTs from different vendors and minimum cost load 
on the DECT portable side. 
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[21] ETSI TS 126 140: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Multimedia Messaging Service (MMS); Media formats and 
codes (3GPP TS 26.140 Release 5)". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in EN 300 175-1 [1] and the following apply: 

MMl reference point: reference point between MMS Relay/Server and MMS User Agent 

MMS Relay/Server: MMS-specific network entity/application that is under the control of an MMS service provider 

NOTE: An MMS Relay/Server transfers messages, provides operations of the MMS that are specific to or 

required by the network environment and provides (temporary and/or persistent) storage services to the 
MMS. 

MMS User Agent: application residing on a fixed net or mobile net terminal or an external device that performs 
MMS-specific operations on a user's behalf 

NOTE: An MMS User Agent is not considered part of an MMSE. 

MM Terminal Equipment: a Terminal Equipment containing an MMS User Agent and an appropriate MMS user 
interface 
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3.2 



Abbreviations 



For the purposes of the present document the following abbreviations apply: 

3GPP 3rd Generation Partnership Project 

AT Access and Terminals 

CI Common Interface 

DECT Digital Enhanced Cordless Telecommunications 

DLC Data Link Control 

DPRS DECT Packet Radio Service 

DSL Digital Subscriber Line 

EN European Norm 

ES End System 

ETSI European Telecommunications Standards Institute 

F-MMS Fixed line-Multimedia Messaging Service 

F-SMS Fixed line-Short Messaging Service 

FT Fixed Termination 

FP Fixed Part 

GAP Generic Access Profile 

GSM Global System for Mobile communications 

HDR High Data Rate 

HLR Home Location Record 

HTTP HyperText Transport Protocol 

ICMP IP Control Management Protocol 

ID IDentifier 

IETF Internet Engineering Task Force 

IP Internet Protocol 

IS Intermediate System 

ISDN Integrated Services Digital Network 

LDR Low Data Rate 

LRMS Low Rate Messaging Service 

MAC Medium Access Control 

MM Multimedia Message 

MMH Multimedia Message Handler 

MMS Multimedia Messaging Service 

MMSE Multimedia Messaging Service Environment 

MMS-HDR MMS High Data Rate 

MMS-LDR MMS Low Data Rate 

MMUA Multimedia Messaging service User Agent 

MMUA-D Multimedia Messaging service User Agent-Destination 

MMUA-O Multimedia Messaging service User Agent-Originator 

NBS Network Based Solution 

NWK NetWorK 

ODAP Open Data Access Profile 

OMA Open Mobile Alliance 

PAP Push Access Protocol 

PDU Protocol Data Unit 

PHL PHisical Layer 

PP Portable Part 

PPG Push Proxy Gateway 

PPP Point to Point Protocol 

PSTN Public Switched Telephone Network 

PT Portable Termination 

REQ REQuest 

RES RESponse 

RFC Request For Comment 

R&TTE Radio communications and Telecommunications Terminal Equipment 

SM Short Message 

SMPP Short Message Peer to Peer protocol 

SMS Short Message Service 

SMSC Short Message Service Centre 
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SMS-C SMS-C-plane 

SMS-U SMS-U-plane 

SM-TL Short Message-Transport Layer 

TCP Transmission Control Protocol 

TISPAN Telecommunications and Internet converged Services and Protocols for Advanced Networking 

TR Technical Report 

TS Technical Specification 

UA User Agent 

UCP Universal Computer Protocol 

UDP User Datagram Protocol 

URI Uniform Resource Identifier 

UMTS Universal Mobile Telecommunications System 

VAS Value Added Services 



General 



The present document is a part of the extensive set of DECT standards produced by EP DECT and covering various 
aspects and needs of communications markets and end users with services ranging from voice to data and multimedia. 

The main focus of the present document is on provision of a F-MMS capable DECT End System (ES) that allows 
distributing the burden of the data applications and transport protocols implementation between the 
DECT Portable Part (PP) and the DECT Fixed Part (FP) targeting of putting the complexity into the FP and reducing 
the complexity, and hence reducing the cost, of the Portable Parts (PPs). 

The present document defines the roles and requirements in regard to the different members of the DECT ES, namely 
the PT and the FT, in the provision of the F-MMS between the access network and the user and is organized in three 
basic groups: 

• Overview to the basic consept and system architecture (clauses 5 and 6); 

• Features definitions (clause 7); 

• Requirements description (clauses 8 and 9). 

Wherever it is possible reference to external standards is used instead of detail description. 



Overview 



The Multimedia Messaging Service (MMS) is a non-real-time delivery service providing a store-and-forward 
mechanism for the provision of messages with a wide range of contents, e.g. text, images, audio and video clips, etc. 

The Fixed line Multimedia Messaging Service (F-MMS) is a service provided via a PSTN or an ISDN fixed network 
(see note). The F-MMS is closely based on the MMS existing in the mobile networks aiming at facilitating the 
interworking with the existing mobile networks MMS, offering the same user experience for both fixed and mobile 
network users and reducing the F-MMS implementation efforts. Following this philosophy, only the mobile 
network-specific transport mechanisms are replaced by transport mechanisms applicable to the fixed networks 
(PSTN/ISDN). The higher, not mobile network-specific MMS protocol layers are used similar to their respective use in 
mobile networks. 

NOTE: An upgrade of the F-MMS in the future may include DSL or other access networks. 

An overview of the relevant standards documents can be found in. TS 102 314-1 [15]. The F-MMS service description 
can be found in ES 202 314-2 [16]. The protocol requirements relevant to a F-MMS capable terminal can be found in 
ES 202 314-4 [17] and TR 102 314-6 [18]. Ongoing and future standardisation development may add new documents to 
this brief list. 
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DECT, as specified in the DECT Common Interface (CI) standards set EN 300 175 parts 1 [1] to 8 [8], is a cordless 
access technology that provides means for cordless delivery of various access networks' services to the end users. To 
satisfy the specific requirements for each access network or/and service and provide basis for interoperable terminal 
implementations the DECT standardisation concept is based on a "base standard - profile relations" resulting in the 
specification of a number DECT profiles standards targeting dedicated access network or/and services. The current 
document is such a profile aimed at specifying interoperable requirements for cordless delivery of F-MMS to the end 
user over a DECT FT- PT pair. 



Reference configuration 



6.1 



General F-IVIIVIS 



The fixed net MMS architecture as defined in ES 202 314-4 [17] is depicted on figure 1. The architecture is similar to 
the MMS architecture in cellular networks, e.g. GSM. The ES 202 314-4 [17] focuses on the definition of the realisation 
of F-MMS on the MMl interface used in a fixed network. 
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Figure 1 : MMS reference architecture 

The F-MMS MMl interface can be seen as a gateway and its general structure from protocol point of view is depicted 
in figure 2. 
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Figure 2: General F-IVIIUIS lUIIVII transport protocol structure 

As specified in ES 202 314-4 [17] the interaction between a MMS User Agent (UA) Originator (MMUA-O), a MMS 
Relay/Server and a MMS UA Destination (MMUA-D) is carried out through a number of transactions and exchange of 
messages that, depending on the procedure, use for underlying transport carrier the Hypertext Transfer Protocol (HTTP) 
or the F-SMS protocols. A generalized transaction sequence of the procedures that may be involved in a MM delivery is 
provided on the figure 3. 
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Figure 3: Generalized F-MMS transaction sequence 
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6.2 



DECT F-MMS reference architecture 



In the case of a DECT phone capable of MMS the notion of a single fixed net phone is substituted for a system 
comprising a DECT FP and one or more DECT PPs where the FP is connected to the MMl interface. This 
configuration is depicted into the figure 4. 
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Figure 4: General DECT F-MMS MMl interface reference model and transport protocol structure 

A DECT system is a distributed system in the sense that the provision of a particular service to the user, in most of the 
cases, involves two separate terminals. Consequently a DECT system can be designed in two basic configurations: 

a) Intermediate System (IS) configuration; where, all or part of the protocols on the MMl interface are handled 
by the PT with the FT acting as a transparent transport. 

b) End System (ES) configuration; where, most of the protocols on the MMl interface are handled by the FT and 
only one or very few higher layer protocols, or even extracted data from such protocols, is transported to the 
PT, i.e. need to be understood by the PT. 

NOTE 1: It is possible that a F-MMS DECT system is designed in which the FP alone provides the MMS, 

including user interface, e.g. means for showing and constructing MMs. Such implementations are out of 
the scope of the present document. 

Various F-MMS DECT IS can be implemented utilising the IP, PPP or V.24 interworking protocols conventions 
defined in DECT Packet Radio Service (DPRS), EN 301 649 [12]. The present document aims at specifying a F-MMS 
DECT ES configuration system. The present document does not specify requirements in regard to provision of MMS 
over streaming - such requirements are left for further study. 

NOTE 2: Streaming here should be understood as the possibility to terminate all protocols in the FT and render the 
MMs to the PT upon user request in real time. 
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Figure 5 provides and example of a DECT F-MMS IS protocol configuration. 
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NOTE 1 : For simplicity the protocol structure in regard to the F-SMSC (i.e. SIVIS handling on the MM1 interface) is 

not shown. 
NOTE 2: The figure does not imply any assumptions on the protocol structure or the physical architecture in the 

accessed network. For simplicity the F-MMS Gateway and Relay/ Server are shown as one entity and 

therefore the MMS protocol handling entity does not represent an actual entity and is simply called 

Multimedia Message Handler. 
NOTE 3: The PP is shown as a single entity which comprises all protocols including the MMUA. Other 

implementations examples include a PP designed as a modem that can handle the PPP but all protocols 

above may be located in an external to the PP terminal, e.g. a PC or PDA. 

Figure 5: A DECT F-MMS IS protocol configuration (DPRS PPP Interworking) 
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Figure 6 provides an example of a DECT F-MMS ES protocol configuration in which no MMS protocol knowledge is 
assumed in the FT. 
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NOTE 1 : For simplicity the protocol structure in regard to the F-SMSC (i.e. SIVIS handling on the MM1 interface) is 

not shown. 
NOTE 2: The figure does not imply any assumptions on the protocol structure or the physical architecture in the 

accessed network. For simplicity the F-MMS Gateway and Relay/ Server are shown as one entity and 

therefore the MMS protocol handling entity does not represent an actual entity and is simply called 

Multimedia Message Handler. 

Figure 6: A DECT F-MMS ES protocol configuration 

Figure 7 provides an example of a Local Server DECT F-MMS ES protocol configuration in which the FT is designed 
as a MMS server (i.e. MMS protocol knowledge is assumed in the FT) where the MM can be stored and the PT can 
display them one by one. In such a configuration the construction of a MM can also be done remotely and the final 
result shown in the PT. 

NOTE 3: Similar service is available today on some Internet sites where the user can choose from a number of 
pictures, sounds, text, video clips, etc. and construct an Internet greetings card, which can be reviewed 
before being sent out. 
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NOTE 1 : For simplicity the protocol structure in regard to the F-SIVISC (i.e. SIVIS handling on the MM1 interface) is 

not shown. 
NOTE 2: The figure does not imply any assumptions on the protocol structure or the physical architecture in the 

accessed network. For simplicity the F-MMS Gateway and Relay/ Server are shown as one entity and 

therefore the MMS protocol handling entity does not represent an actual entity and is simply called 

Multimedia Message Handler. 
NOTE 3: The MMUA* depicts the implementation possibility the PI to provide a limited MMUA functionality. 

Figure 7: A local FT server DECT F-MMS ES protocol configuration 

The specification of Local Server DECT F-MMS ES is left for further study. 
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Feature definitions 



For the purposes of the present document the following feature definitions apply. The procedures relevant to each 
feature are described in clauses 8 and 9. 

Submission of an MM: DECT F-MMS system's ability to establish, maintain and release a suitable DECT bearer 
between a PT and a FT; transmit a MM from the PT to the FT utilising this bearer; and, submit the MM from the FT to 
a known F-MMS Gateway - Relay/Server together with sufficient addressing information for one or multiple called 
parties and optionally MM terminal equipment capabilities. 

MM notification: DECT FT's ability to communicate with a fixed network SMSC, receive and understand a SMS 
message carrying notification from F-MMS Relay/Server referring to a MM received by the F-MMS Relay/Server and 
addressed to one of the FT users; DECT F-MMS system's ability to establish, maintain and release a suitable DECT 
bearer between a PT and a FT and transmit the notification from the FT to the PT utilising this bearer. 

NOTE: A received MM notification should result in suitable indication provided to the User. 

MM retrieval: DECT F-MMS system's ability to establish, maintain and release a suitable DECT bearer between a PT 
and a FT; request MM retrieval for a MM for which notification has been received from the PT to FT and from the FT 
to the F-MMS Gateway - Relay/Server; retrieve that referred message from the F-MMS Gateway - Relay/Server to the 
FT and transmit it over the DECT bearer to the PT together with information for the sender and optionally information 
regarding action the F-MMS Gateway - Relay/Server has taken in respect to MM terminal equipment capabilities. 

NOTE: MM retrieval may be started explicitly upon user request or may be set by the user to be executed 
automatically upon receipt of MM notification. 
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MM delivery report: DECT FT's ability to communicate with a fixed network SMSC, receive and understand a SMS 
message carrying delivery report from F-MMS Relay/Server referring to a MM submitted by the FT and being 
delivered to its addressee; DECT F-MMS system's ability to establish, maintain and release a suitable DECT bearer 
between a PT and a FT and transmit the MM delivery report from the FT to the PT utilising this bearer. 

NOTE: A received MM delivery report should result in suitable indication provided to the User. 

MM read report (MM receiving side): DECT F-MMS system's ability to establish, maintain and release a suitable 
DECT bearer between a PT and a FT; DECT MM PT ability, after the user has read a received MM and, if the sender 
has requested a read report, to transmit a MM from the PT to the FT utilising this bearer; and, FT's ability to indicate the 
event to the F-MMS Relay/Server referring to the MM being read. 

MM read report (MM sending side): DECT FT's ability to communicate with a fixed network SMSC, receive and 
understand a SMS message carrying MM read report from F-MMS Relay/Server referring to a MM submitted by the FT 
and being read by its addressee; DECT F-MMS system's ability to establish, maintain and release a suitable DECT 
bearer between a PT and a FT and transmit the MM delivery report from the FT to the PT utilising this bearer. 

NOTE: A received MM read report should result in suitable indication provided to the User. 

MM forwarding: DECT F-MMS system's ability to establish, maintain and release a suitable DECT bearer between a 
PT and a FT; request (from the PT to the FT and from the FT to the F-MMS Gateway - Relay/Server ) MM forwarding 
to a preferred address for a MM for which notification has been received. 

Service operation setting: DECT F-MMS system's ability to set and exchange MM service operation relevant 
information, e.g. PT and FT terminals capabilities, service provider/network operator service provision settings, 
sub-addressing, etc. 

Interconnection with access networks: DECT FT ability to establish suitable communication channels with the 
relevant fixed line access network for the provisioning of F-MMS utilising various communication protocols, e.g. PPP, 
IP/TCP/UDP, V.90, F-SMS, etc. 



8 DECT protocol elements of procedures 

This clause specifies DECT protocol procedures, messages and information elements that should be used for the 
provision of F-MMS by a DECT set comprising of a FT and at least one PT. 

This specification does not prevent any PT or FT from implementing requirements not specified in this document. A PT 
or FT receiving an unsupported message or information element which it does not recognize shall ignore it as specified 
in EN 300 175 parts 3 [3] to 5 [5]. 

NOTE: The MMl messages mentioned in the present document are abstract protocol messages according to the 
terminology used in 3GPP. More information about these abstract protocol messages and the PDUs they 
may represent can be found in various OMA documents. For the relevant documents consult 
ES 202 314-4 [17]. 

8.1 General 

8.1.1 DECT Transport 

The F-MMS service protocol requirements as specified in ES 202 314-4 [17] divide the F-MMS protocol in two basic 
sets of procedures depending on the transport used for the F-MMS PDUs: 

1) procedures utilising HTTP as transport; 

2) procedures utilising the F-SMS as transport. 

To satisfy the requirements of procedures' set 1) the current document provides: 

a) a MMS High Data Rate (MMS-HDR) solution based on transport mechanism specified in the EN 301 649 [12]; 

b) a MMS Low data rate (MMS-LDR) solution based on transport mechanism specified in TS 102 342 [14]. 
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All DECT terminals that claim compliance with the current document shall support either MMS-HDR or MMS-LDR or 
both transport mechanism(s). The indication of MMS transport mechanism option supported is defined by clause 8.8.1 
"DECT Terminal capabilities indication" of this document. 

To satisfy the requirements of procedures' set 2) the current document provides: 

a) a SMS C-plane (SMS-C) solution based on transport mechanism specified in the EN 300 757 [13]; 

b) a SMS U-plane (SMS-U) solution specified in the current document. 

All DECT terminals that claim compliance with the current document shall support either SMS-C or SMS-U or both 
solution(s). The indication of SMS transport mechanism option supported is defined by clause 8.8.1 "DECT Terminal 
capabilities indication" of this document. 

8.1.2 Applications 

PPs that comply to the current document shall provide the user with the capability to assemble a MM. The means for 
collecting different MM components, e.g. retrieval or direct drawing of a picture, retrieval or recording of audio or 
video, etc., and their presentation to the user are out of the scope of this document. 

PPs that comply to the current document shall provide the user with the capability to view a MM. 

To be able to assemble or/and view a MM, the PPs shall comply to the requirements as specified in TS 123 140 [20] 
andTS 126 140 [21]. 

8.2 MM submission 

All FTs that comply to the requirements of the present document for the provision of F-MMS shall comply to the 
requirements specified in ES 202 314-4 [17] clauses 5.1 and 7.3 and the requirements specified in the current clause. 
All PTs shall comply to subset of ES 202 314-4 [17] as specified in the current clause. 

8.2.1 IVIIVIS-HDR (IVIIVI submission) 

If a PP wants to send a MM using the MMS-HDR option, it shall start a DPRS call as specified in EN 301 649 [12]. The 
PP shall use the DPRS Frame Relay Service with the profile subtype DECT Generic Media Encapsulation and 
Application Communication Port HTTP and shall conform to all relevant requirements as specified in EN 301 649 [12]. 

Both PT and FT shall support the HTTP RFC 2616 [19] and HTTP messages shall be transported over the thus provided 
DPRS bearer. That is, the DPRS call shall provide transport mechanism between the two HTTP entities, one residing in 
the PT and the other in the FT. 

The PT shall construct a MMl_submit.REQ message and shall send it to the FT using the HTTP as defined in 
ES 202 314-4 [17]. The HTTP entity in FT is responsible to recognize the MMl_submit.REQ message and submit it to 
the FT MMS-UA. When the FT MMS-UA receives the MMl_submit.REQ it shall act as this message was constructed 
by the FT MMS-UA itself, shall establish a connection to the MMS Relay/Server as specified in ES 202 314-4 [17] and 
transmit the message to the MMS Relay/Server. The response from the MMS Relay/Server, i.e. the MMl_submit.RES 
message shall be relayed by the FT to the PT and the DECT call should be released. Information that the message was 
successfully transmitted should be delivered to the User. 
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Figure 8: An example abstract message flow for successful MM submission 

8.2.2 MMS-LDR (MM submission) 

For the low data rate implementations all requirements relevant for the high data rate implementations shall apply with 
the exception that when the PP wants to send a MM it shall establish an ODAP call as specified in TS 102 342 [14]. 



8.3 



MM notification 



All FTs that comply to the requirements of the present document for the provision of F-MMS shall comply to the 
requirements specified in ES 202 314-4 [17] clauses 5.2.1 and 7.2 and the requirements specified in the current clause. 
All PTs shall comply to subset of ES 202 314-4 [17] as specified in the current clause. 

8.3.1 SMS-C (MM notification) 

Upon receipt of an SMS message that can be identified as carrying a MMl_notification.REQ message the FT, which 
supports SMS-C option and if the PT supports the SMS-C option too, shall establish a DECT call and transmit the SMS 
message to the PT as specified in clause 7, Short Message Service (SMS), of EN 300 757 [13]. The PT shall inform the 
user about the received notification. 

NOTE: The means for informing the user about the received notification and the presentation of the information 
to the user are out of the scope of the present document. 
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Figure 9: An example abstract message flow for MM notification C-Plane 

8.3.2 SMS-U (MM notification) 

Upon receipt of an SMS message that can be identified as carrying a MMl_notification.REQ message the FT, which 
supports SMS-U option and if the PT supports the SMS-U option too, shall extract the MM-notification.REQ message 
and depending on the supported transport shall continue in one of the following ways: 

a) The FT shall estabHsh a DPRS call as specified in EN 301 649 [12] utiHsing the DPRS Frame Relay Service 
with the profile subtype DECT Generic Media Encapsulation and Application Communication Port HTTP. The 
MMl_notification.REQ shall be attached to a HTTP PDU and transported to the PT. All relevant requirements 
as specified in EN 301 649 [12] shall be obeyed; for the HTTP utilisation the same requirements as in the case of 
the MM submission shall apply. 

b) The FT shall establish a ODAP call as specified in TS 102 342 14]. The MMl_notification.REQ shall be 
attached to a HTTP PDU and transported to the PT. All relevant requirements as specified in TS 102 342 [14]; 
for the HTTP utilisation the same requirements as in the case of the MM submission shall apply. 

The PT shall inform the user about the received notification. 

NOTE: The means for informing the user about the received notification and the presentation of the information 
to the user are out of the scope of the present document. 
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Figure 10: An example abstract message flow for MM notification U-plane 



8.4 



MM retrieval 



All FTs that comply to the requirements of the present document for the provision of F-MMS shall comply to the 
requirements specified in ES 202 314-4 [17] clauses 5.2.2 and 7.3 and the requirements specified in the current clause. 
All PTs shall comply to subset of ES 202 314-4 [17] as specified in the current clause. 

The MM retrieval procedure can be started by the PT without user intervention immediately after the 
MMl_notification.REQ has been received (automatic retrieval, i.e. immediate retreival); alternatively, the PT may 
await explicit request from the user to initiate the MM retrieval procedure (manual retrieval, i.e. diferred retrieval). 

NOTE: An FT may be designed to act as a local server and start the MM retrieval procedure without awaiting 
request from the PT. On this case the PT initiated procedure will be local and will not have significance 
for the accessed network. Such FTs should implement message handling/storage policies similar to a MM 
Server especially in regard to delivery/read reports. 

8.4.1 MMS-HDR (MM retrieval) 

If a PP wants to retrieve a MM using the MMS-HDR option, it shall start a DPRS call as specified in EN 301 649 [12]. 
The PP shall use the DPRS Frame Relay Service with the profile subtype DECT Generic Media Encapsulation and 
Application Communication Port HTTP and shall conform to all relevant requirements as specified in EN 301 649 [12]. 

Both PT and FT shall support the HTTP RFC 2616 [19] and HTTP messages shall be transported over the thus provided 
DPRS bearer. That is, the DPRS call shall provide transport mechanism between the two HTTP entities, one residing in 
the PT and the other in the FT. 
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The PT shall construct a MMl_retrieve.REQ message and shall send it to the FT using the HTTP as defined in 
ES 202 314-4 [17]. The HTTP entity in FT is responsible to recognize the MMl_retrieve.REQ message and submit it to 
the FT MMS-UA. When the FT MMS-UA receives the MMl_retrieve.REQ it shall act as this message was constructed 
by the FT MMS-UA itself, shall establish a connection to the MMS Relay/Server as specified in ES 202 314-4 [17] and 
transmit the message to the MMS Relay/Server. The response from the MMS Relay/Server, i.e. the MMl_retrieve.RES 
message shall be relayed by the FT to the PT and the DECT call should be released. Information that the message was 
successfully transmitted should be delivered to the User. 

Depending on the type of retrieval used, e.g. deferred retreival or immediate retrieval, prior to constructing and 
transmitting the MMl_retrieve.REQ message the PT may have to construct and submit a MMl_notification.RES 
message and after the MM has been retrieved the PT may have to construct and submit a MMl_acknowledgement.REQ 

message. 
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Figure 11 : An example abstract message flow for MM retrieval U-plane 

8.4.2 MMS-LDR (MM retrieval) 

For the low data rate implementations all requirements relevant for the high data rate implementations shall apply with 
the exception that when the PP wants to retrieve a MM it shall establish an ODAP call as specified in TS 102 342 [14]. 

8.5 MM delivery report 

All FTs that comply to the requirements of the present document for the provision of F-MMS shall comply to the 
requirements specified in ES 202 314-4 [17] clauses 5.3.1 and 7.2 and the requirements specified in the current clause. 
All PTs shall comply to subset of ES 202 314-4 [17] as specified in the current clause. 
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8.5.1 SMS-C (MM delivery report) 



Upon receipt of an SMS message that can be identified as carrying a MMl_delivery_report.REQ message the FT, 
which supports SMS-C option and if the PT supports the SMS-C option too, shall establish a DECT call and transmit 
the SMS message to the PT as specified in clause 7, Short Message Service (SMS), of EN 300 757 [13]. The PT shall 
inform the user about the received report. 

NOTE: The means for informing the user about the received report and the presentation of the information to the 
user are out of the scope of the present document. 
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Figure 12: An example abstract message flow for MM delivery report C-Plane 

8.5.2 SMS-U (MM delivery report) 

Upon receipt of an SMS message that can be identified as carrying a MMl_delivery_report.REQ message the FT, 
which supports SMS-U option and if the PT supports the SMS-U option too, shall extract the MM-notification.REQ 
message and depending on the supported transport shall continue in one of the following ways: 

c) The FT shall establish a DPRS call as specified in EN 301 649 [12] utihsing the DPRS Frame Relay Service 
with the profile subtype DECT Generic Media Encapsulation and Application Communication Port HTTP. The 
MMl_notification.REQ shall be attached to a HTTP PDU and transported to the PT. All relevant requirements 
as specified in EN 301 649 [12] shall be obeyed; for the HTTP utilisation the same requirements as in the case of 
the MM submission shall apply. 

d) The FT shall establish a ODAP call as specified in TS 102 342 [14]. The MM 1 .notification. REQ shall be 
attached to a HTTP PDU and transported to the PT. All relevant requirements as specified in TS 102 342 [14]; 
for the HTTP utilisation the same requirements as in the case of the MM submission shall apply. 

The PT shall inform the user about the received report. 

NOTE: The means for informing the user about the received report and the presentation of the information to the 
user are out of the scope of the present document. 
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Figure 13: An example abstract message flow for MM delivery report U-Plane 



8.6 MM read report 



All FTs that comply to the requirements of the present document for the provision of F-MMS shall comply to the 
requirements specified in ES 202 314-4 [17] clauses 5.3.2 and 7.2 or 7.3 (whichever relevant) and the requirements 
specified in the current clause. All PTs shall comply to subset of ES 202 314-4 [17] as specified in the current clause. 

The MM read report procedure consists of two transactions executed at different places and at different times. The first 
transaction (MM read report from MM destination) takes place at the MM destination site after the recipient of an MM 
reads the MM. As a consequence a report is sent from the MM destination to the MMS Relay Server. The second 
transaction (MM read report to MM originator) takes place at the MM originator site when the MMS Relay Server 
sends a report to the Originator of the MM via a SMSC that its MM was read. 

NOTE: The procedure activation depends on events out of the procedure itself, e.g. if originator has requested a 
read report and if the destination has allowed a read report to be sent. Each of these actions may be 
determined by the terminals' capabilities, the service features or the users wish. 



8.6.1 MM read report from MM destination 



8.6.1.1 



MMS-HDR (MM read report from MM destination) 



If a MM read report has been requested, and if it is supported by the recipient terminal and permitted by the user, after 
the recipient user reads the MM, the PP, which supports the MMS-HDR option, shall start a DPRS call as specified in 
EN 301 649 [12]. The PP shall use the DPRS Frame Relay Service with the profile subtype DECT Generic Media 
Encapsulation and Application Communication Port HTTP and shall conform to all relevant requirements as specified 

in EN 301 649 [12]. 

Both PT and FT shall support the HTTP RFC 2616 [19] and HTTP messages shall be transported over the thus provided 
DPRS bearer. That is, the DPRS call shall provide transport mechanism between the two HTTP entities, one residing in 
the PT and the other in the FT. 
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The PT shall construct a MMl_read_reply_recipient.REQ message and shall send it to the FT using the HTTP as 
defined in ES 202 314-4 [17]. The HTTP entity in FT is responsible to recognize the MM1_ read_reply_recipient.REQ 
message and submit it to the FT MMS-UA. When the FT MMS-UA receives the MM1_ read_reply_recipient.REQ it 
shall act as this message was constructed by the FT MMS-UA itself, shall establish a connection to the MMS 
Relay/Server as specified in ES 202 314-4 [17] and transmit the message to the MMS Relay/Server. 
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Figure 14: An example abstract message flow for MM read indication recipient side 

8.6.1 .2 MMS-LDR (MM read report from MM destination) 

For the low data rate implementations all requirements relevant for the high data rate implementations shall apply with 
the exception that when the PP wants to send indication that a MM was read it shall establish an ODAP call as specified 
inTS 102 342 [14]. 

8.6.2 MM read report to MM originator 
8.6.2.1 SMS-C (MM read report to MM originator) 

Upon receipt of an SMS message that can be identified as carrying a MM1_ read_reply_originator.REQ message the 
FT, which supports SMS-C option and if the PT supports the SMS-C option too, shall establish a DECT call and 
transmit the SMS message to the PT as specified in clause 7, Short Message Service (SMS), of EN 300 757 [13]. The 
PT shall inform the user about the received report. 

NOTE: The means for informing the user about the received report and the presentation of the information to the 
user are out of the scope of the present document. 
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8.6.2.2 



Figure 15: An example abstract message flow for MM delivery report C-Plane 



SMS-U (MM read report to MM originator) 



Upon receipt of an SMS message that can be identified as carrying a MM1_ read_reply_originator.REQ message the 
FT, which supports SMS-U option and if the PT supports the SMS-U option too, shall extract the 
MMl_read_reply_originator.REQ message and depending on the supported transport shall continue in one of the 
following ways: 

e) The FT shall estabUsh a DPRS call as specified in EN 301 649 [12] utiUsing the DPRS Frame Relay Service 
with the profile subtype DECT Generic Media Encapsulation and Application Communication Port HTTP. The 
MM1_ read_reply_originator.REQ shall be attached to a HTTP PDU and transported to the PT. All relevant 
requirements as specified in EN 301 649 [12] shall be obeyed; for the HTTP utilisation the same requirements as 
in the case of the MM submission shall apply. 

f) The FT shall establish a ODAP call as specified in TS 102 342 [14]. The MMl_read_reply_originator.REQ shall 
be attached to a HTTP PDU and transported to the PT. All relevant requirements as specified in 

TS 102 342 [14]; for the HTTP utilisation the same requirements as in the case of the MM submission shall 
apply. 

The PT shall inform the user about the received report. 

NOTE: The means for informing the user about the received report and the presentation of the information to the 
user are out of the scope of the present document. 



8.7 MM forwarding 



All FTs that comply to the requirements of the present document for the provision of F-MMS shall comply to the 
requirements specified in ES 202 314-4 [17] clauses 5.4 and 7.3 and the requirements specified in the current clause. 
All PTs shall comply to subset of ES 202 314-4 [17] as specified in the current clause. 
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The MM forwarding procedure consists of one transaction. After having received an MM Notification, the recipient (the 
user or the PP if it has been set by the user automatically to do so) can request that the MM is forwarded to other 
addressees without having first to retrieve the MM. 

8.7.1 MMS-HDR (MM forwarding) 

If a PP, which supports the MMS-HDR option, wants to forward a message to another address, after notification has 
been received and before the message has been retrieved, it shall start a DPRS call as specified in EN 301 649 [12]. The 
PP shall use the DPRS Frame Relay Service with the profile subtype DECT Generic Media Encapsulation and 
Application Communication Port HTTP and shall conform to all relevant requirements as specified in EN 301 649 [12]. 

Both PT and FT shall support the HTTP RFC 2616 [19] and HTTP messages shall be transported over the thus provided 
DPRS bearer. That is, the DPRS call shall provide transport mechanism between the two HTTP entities, one residing in 
the PT and the other in the FT. 

The PT shall construct a MMl_forward.REQ message and shall send it to the FT using the HTTP as defined in 
ES 202 314-4 [17]. The HTTP entity in FT is responsible to recognize the MM1_ forward. REQ message and submit it 
to the FT MMS-UA. When the FT MMS-UA receives the MM1_ forward.REQ it shall act as this message was 
constructed by the FT MMS-UA itself, shall establish a connection to the MMS Relay/Server as specified in 
ES 202 314-4 [17] and transmit the message to the MMS Relay/Server. The response from the to the MMS 
Relay/Server, i.e. the MM1_ forward.RES message shall be relayed by the FT to the PT and the DECT call should be 
released. Information that the procedure was successfully accomplished should be delivered to the User. 
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Figure 16: An example abstract message flow for successful MM forwarding 
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8.7.2 MMS-LDR (MM forwarding) 

For the low data rate implementations all requirements relevant for the high data rate implementations shall apply with 
the exception that when the PP wants to request MM forwarding it shall establish an ODAP call as specified in 
TS 102 342 [14]. 

8.8 Service operation settings 

8.8.1 DECT Terminal capabilities indication 

The support of the F-MMS interworking profile described in this document shall be indicated by the FT by setting on 
the "F-MMS interworking profile supported" bit in the FT's Extended fixed part capabilities Qt message and by the PT 
by setting on the "F-MMS interworking profile supported" bit in the <Profile/ Application Indicator_6> field of the 
«Terminal-capability» information element during obtaining access rights and location registration procedures as 
specified in EN 300 444 [10]. 

In addition FTs and PTs shall indicate the exact mechanism used for transporting the F-MMS information on the DECT 
air interface, i.e. High Data Rate (HDR) or Low Data Rate (LDR), and, SMS C-plane (SMS-C) or SMS U-plane 
(SMS-U) respectively. 

Table 1 : Values used in Extended FP capabilities (QH=4) 



Bit Nr. 


Attribute 


Value 


Note 


a25 


F-MMS Interworking profile 
supported 


1 


Implies that F-MMS service is supported the exact 
mode of transport is indicated additionally. 


a26 


ODAP supported 


All 


a25 and a26 set imply that F-MMS service will be 
using the LDR option. 


a27 


Generic Media Encapsulation 
transport (DPRS) supported 


All 


a25 and a27 set imply that F-MMS service will be 
using the HDR option. 


a43 


LRMS 


All 


a25 and a43 set implies that F-MMS service will be 
using the SMS-C. If a43 is not set, the setting of bits 
a26 and a27 in conjuction with a25 being set will 
determine which of the SMS-U options will be used. 



Table 2: Values used within the «TERMINAL CAPABILITY» information element 



Information 
element 


Field within the 
Information element 


Standard values within the 
field/Information element 


Normative action/comment 


«Terminal 
capability» 






Octets 1 and 2 set in accordance with 
in EN 300 175-5 [5] clause 7.7.41 


<ext 3> 


1 


No other octets from Octet group 3 
included (see note 1) 


<Tone capability> 


001 


No tone capability 


<Display capability> 


0001 


No display 


<ext 4> 







<Profile indicator_1> 


XX 1 xxxx 


Implies that F-MMS service is 
supported using the SMS-C. If this bit 
is not set, the setting of the relevant 
bits in <Profile indicator_5> and 
<Profile indicator_6> will determine 
which of the SMS-U options will be 
used, (see notes 2 and 4) 


<ext 4a> 







<Profile indicator 2> 


xxxxxxx 


(See note 2) 


<ext 4b> 







<Profile indicator 3> 


xxxxxxx 


(See note 2) 


<ext 4c> 







<Profile indicator_4> 


1 xxxxxx 


Generic Media Encapsulation 
transport (DPRS) supported. Implies 
that F-MMS service is supported 
using the HDR option, (see notes 2 
and 4) 
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Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 




<ext 4d> 







<Profile indicator 5> 


xxxxxxx 


(See note 2) 


<ext 4e> 


1 


No other octets from Octet group 4 
included 


<Profile indicator_6> 


xxxllxx 


Implies that F-MMS service is 
supported using the LDR option, (see 
notes 2 and 4) 


XXX 1 XXX 


F-MMS Interworking profile supported 
(see notes 2 and 3) 


<ext 5> 


1 




<Control codes> 


000 


Not specified 


<ext 6> 


0/1 




<Blind Slot lndication> 


All 


As appropriate 


<SPx> 


All 


As appropriate 


<ext 6a> 


1 


Present if <ext 6> = 


<SPx> 


All 


As appropriate 


NOTE 1 : Implies that <Slot type capability> = Full slot. 

NOTE 2: Bits indicated with "x" shall be sent in accordance to the support provided by the terminal - these bits are 

not relevant to the F-MMS provision. 
NOTE 3: Implies that F-IVIMS service is supported the exact mode of transport is indicated additionally. 
NOTE 4: The setting of this bit has implication on the F-MMS service only if the <Profile indicator_6> has been set 

to indicate "F-MMS interworking profile supported". 



8.8.2 MMS Terminal capability negotiation 



DECT FTs and PTs supporting F-MMS should support the MMS terminal capability negotiation procedure as specified 
in ES 202 314-4 [17], clauses 6 and 6.2. 

DECT PTs should provide their terminal capabilities at least once and the DECT FT should store the information for 
future use. If FT does not provide its MMS terminal capability the FT should retrieve any stored locally information and 
use it in its communication with the MMSE. If information is not available the FT shall act as a MMTE which does not 
support terminal capability negotiation as specified in ES 202 314-4 [17], clauses 6.1. 

NOTE: For PTs sold together with a FT manufacturers may choose to have the PT's MMS terminal capabilities 
pre-stored in the FT. The PT should still be able to send its MMS terminal capabilities or otherwise such 
PTs may not be able to support MMS terminal capability negotiation when used with FTs from other 
vendors. 

If the MMSE provides back information on the MMS terminal capability, FT shall provide this information to the PT. 



8.8.3 Configuration profile setting 



For successful operation of the F-MMS a number of, per user, parameters need to be configured or values need to be 
provided. 

The values may be made available to the FT via one specially designated PT, via any PT that supports the F-MMS or, 
through any suitable proprietary interface, e.g. over a wired connection to a PC. The former and the latter are left to 
manufacture of the FT to choose any suitable solution. It is assumed that DECT solutions are sold as a set that includes 
one FP and at least one PP from the same manufacturer. 

For the provision of the possibility parameters to be provided via PPs from different vendors than those supplying the 
FP the DECT keypad protocol as defined in EN 300 175-5 [5], clause 10.2 should be supported. The FT should request 
a particular parameter by sending a «Multi-display» information element containing the parameter name and the 
value provided by the user in response shall be included in single «Multi-keypad» information element. 

All DECT terminals that claim compliance with the current document shall support the parameters defined in 
ES 202 314-4 [17] clauses 8.2.3 and 8.2.4. 
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8.8.4 Service administration 



It is up to the F-MMS provider to define procedures for registration, activation, deactivation etc. These procedures may 
be based on SMS (e.g. using service codes), MMS (e.g. using service codes), Internet or other communication systems. 

If SMS or MMS are used, DECT PT and FT should use the normal transport mechanism they use for the provision of 
SMS or MMS in regard to the standard F-MMS service procedures described in clause 9 of the current document. 



8.8.5 Sub-addressing 



The DECT multi -handset per base station capability allows for the provision of more than one MMTE connected in 
parallel to the same subscriber line. If this is to be supported the mechanism of MMS sub-addressing shall be provided. 
The sub-addressing may be used also to allow the use of personal MM mailboxes within the MMTEs. DECT terminals 
that provide sub-addressing shall comply with the requirements specified in ES 202 314-4 [17], clauses 8.1. 



Interconnection with access networks 



This clause provides information and requirements in regard to the interconnection of the DECT system with the access 
network. 

The ES 202 314-4 [17] provides requirements for interconnection to PSTN and ISDN networks. Future extensions to 
the F-MMS service may provide interconnection requirements to other networks, e.g. DSL. 

9.1 General 

DECT FTs that claim compliance with the current document shall comply with the requirements specified in 
ES 202 314-4 [17] clauses 7.3.3 and support PPP, IP, ICMP, TCP, UDP and HTTP protocols for the provision of 
transport mechanism for the F-MMS procedures using these protocols. 

In addition, all FTs shall comply with the requirements specified in ES 202 314-4 [17] clauses 7.2 and support the fixed 
network Short Message Service protocol(s) for the provision of transport mechanism for the F-MMS procedures using 
these protocols. 

9.2 PSTN access 

DECT FTs that claim compliance with the current document and connected to the network via PSTN shall comply with 
the requirements specified in ES 202 314-4 [17], clause 8.2.2.1 and support at least one of the modem protocols V.32, 
V.32bis, V.34, V.90, V.92. 

9.3 ISDN access 

DECT FTs that claim compliance with the current document and connected to the network via ISDN shall comply with 
the requirements specified in ES 202 314-4 [17], clause 8.2.2.2 and support shall support the ISDN "unrestricted digital 
information" bearer. 
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